summaryrefslogtreecommitdiffstats
path: root/fpm (follow)
Commit message (Collapse)AuthorAgeFilesLines
* *: add XREF_SETUP() to libraries and utilitesDavid Lamparter2024-05-021-0/+5
| | | | | | | | | This is theoretically not needed if neither DEFUNs nor zlog_* calls are used, except I'm about to turn it into a build error to catch the cases where it _is_ necessary. Which is libmgmt_be_nb.la in this case, where it causes build failures on hppa. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* fpm: Add func to encode SRv6 SIDs in protobufCarmine Scarpitta2024-02-181-0/+308
| | | | | | | | | | | | | | | | | Add a bunch of helper functions to support encoding of SRv6 SIDs in protobuf. Specifically, * `fpm_srv6_sid_format_create`: encode SID format information into a protobuf `SRv6SIDFormat` structure * `fpm_srv6_local_sid_*_behavior_create` functions: encode an SRv6 SID behavior and associated attributes into a protobuf `Fpm__SRv6LocalSID__*` structure This is a preliminary commit to support sending SRv6 Local SIDs and VPN SIDs via protobuf. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* fpm: Add functions to encode nexthop in protobufCarmine Scarpitta2024-02-181-0/+92
| | | | | | | | | | | | | | | Add two helper functions to encode/decode nexthops in protobuf. Specifically, * `fpm_nexthop_create`: encode a `struct nexthop` in a protobuf nexthop structure * `fpm_nexthop_get`: decode a nexthop protobuf structure into a `struct nexthop` This is a preliminary commit to support sending SRv6 Local SIDs and VPN SIDs via protobuf. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* fpm: Add SRv6 VPN SIDs to `fpm.proto`Carmine Scarpitta2024-02-181-0/+5
| | | | | | | | | | | | | | | | Add two optional fields to the AddRoute protobuf message to support SRv6 VPN use cases: * `srv6_vpn_sid`: used to associate an SRv6 VPN SID to a route; if present, the router will steer the traffic that matches the prefix by encapsulating the payload in an outer IPv6 header where the destination address is the SRv6 VPN SID provided * `srv6_encap_source_address`: source Address of outer encapsulating IPv6 header This is a preliminary commit to support sending SRv6 Local SIDs and VPN SIDs via protobuf. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* fpm: Add SRv6 Local SIDs to `fpm.proto`Carmine Scarpitta2024-02-181-0/+140
| | | | | | | | | | Add several protobuf messages to support the installation and removal of SRv6 Local SIDs via FPM protobuf. This is a preliminary commit to support sending SRv6 Local SIDs and VPN SIDs via protobuf. Signed-off-by: Carmine Scarpitta <cscarpit@cisco.com>
* *: create a single registry of daemons' default port valuesMark Stapp2024-02-011-5/+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>
* *: auto-convert to SPDX License IDsDavid Lamparter2023-02-092-32/+2
| | | | | | Done with a combination of regex'ing and banging my head against a wall. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: manual SPDX License ID conversionsDavid Lamparter2023-02-092-31/+2
| | | | | | | | | | The files converted in this commit either had some random misspelling or formatting weirdness that made them escape automated replacement, or have a particularly "weird" licensing setup (e.g. dual-licensed.) This also marks a bunch of "public domain" files as SPDX License "NONE". Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* build: fix `AM_LDFLAGS` usage (and gcov)David Lamparter2021-07-211-1/+1
| | | | | | | | | | | | | | | | like the other automake variables, setting `xyz_LDFLAGS` causes `AM_LDFLAGS` to be ignored for `xyz`. For some reason I had in my mind that automake doesn't do this for LDFLAGS, but... it does. (Which is consistent with `_CFLAGS` and co.) So, all the libraries and modules have been ignoring `AM_LDFLAGS` (which includes `SAN_FLAGS` too). Set up new `LIB_LDFLAGS` and `MODULE_LDFLAGS` to handle all of this correctly (and move these bits to a central location.) Fixes: #9034 Fixes: 0c4285d77eb ("build: properly split CFLAGS from AC_CFLAGS") Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* build: make builddir include path consistentDavid Lamparter2021-04-211-1/+1
| | | | | | | ... by referencing all autogenerated headers relative to the root directory. (90% of the changes here is `version.h`.) Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: Replace `sizeof something` to sizeof(something)Donatas Abraitis2020-03-081-1/+1
| | | | | | Satisfy checkpatch.pl requirements (check for sizeof without parenthesis) Signed-off-by: Donatas Abraitis <donatas.abraitis@gmail.com>
* build: fix "make tags"David Lamparter2019-09-171-0/+4
| | | | | | | | | | | Anything we list in a xxx_SOURCES variable will be included for "make tags", including filess marked as nodist_xxx_SOURCES. So if we don't have Protobuf enabled, even though the entire library isn't built, "make tags" will still try to process these files... which we can't autogenerate because Protobuf is disabled. Same for gRPC. Fixes: #3266 Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: s/TRUE/true/, s/FALSE/false/Quentin Young2019-07-011-2/+2
| | | | Signed-off-by: Quentin Young <qlyoung@cumulusnetworks.com>
* build: disable empty libfrrfpm_pbDavid Lamparter2018-12-131-2/+2
| | | | | | | We were building and installing an _empty_ library (i.e. it literally didn't contain anything.) Signed-off-by: David Lamparter <equinox@diac24.net>
* build: clean up protobuf build integrationDavid Lamparter2018-09-081-4/+6
| | | | | | | We were linking all libs and binaries against libprotobuf-c if the option was enabled... that makes no sense at all. Signed-off-by: David Lamparter <equinox@diac24.net>
* *: cleanup .gitignore filesDavid Lamparter2018-09-081-15/+0
| | | | Signed-off-by: David Lamparter <equinox@diac24.net>
* build: clean up BUILT_SOURCESDavid Lamparter2017-08-041-1/+0
| | | | | | | | | | | | | | | BUILT_SOURCES doesn't do what the name suggests. What it actually means is "these files should be built first when doing a 'make' without explicit target" (or "make all"). It's pretty much almost always wrong to use BUILT_SOURCES, the only correct use is when a file is needed by an unspecified / large set of files. Also remove version.h and route_types.h from dist tarball while we're at it. configure will create them anyway. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* protobuf: fix buildDavid Lamparter2017-07-311-0/+2
| | | | Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* build: non-recursive qpb & fpmDavid Lamparter2017-07-314-30/+34
| | | | Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: reindentreindent-master-afterwhitespace / reindent2017-07-172-103/+91
| | | | | | indent.py `git ls-files | pcregrep '\.[ch]$' | pcregrep -v '^(ldpd|babeld|nhrpd)/'` Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: make consistent & update GPLv2 file headersDavid Lamparter2017-05-152-8/+6
| | | | | | | | | | | The FSF's address changed, and we had a mixture of comment styles for the GPL file header. (The style with * at the beginning won out with 580 to 141 in existing files.) Note: I've intentionally left intact other "variations" of the copyright header, e.g. whether it says "Zebra", "Quagga", "FRR", or nothing. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* *: Convert libfpm -> libfrrfpmDonald Sharp2017-02-031-4/+4
| | | | | | | Convert the libfpm to libfrrfpm to prevent namespace collision with Quagga. Signed-off-by: Donald Sharp <sharpd@cumulusnetworks.com>
* Use only the ISC license for .proto files.Avneesh Sachdev2016-09-231-31/+0
| | | | | | | | | | Simplify licensing for protobuf files based on discussion on the quagga-dev mailing list. Previously, users could choose between the GPL and the ISC license. Signed-off-by: Avneesh Sachdev <avneesh@sproute.com> Signed-off-by: Avneesh Sachdev <avneesh@sproute.com>
* fpm: Add protobuf support for FPM.Avneesh Sachdev2016-09-236-8/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Code that allows a client to convey routes to a Forwarding Plane Manager component using protobuf instead of netlink.. * fpm/fpm.proto Protobuf definitions pertaining to the Forwarding Plane Manager. In particular, this file defines the AddRoute and DeleteRoute messages. * fpm/fpm.h Tweak FPM message header definition to also allow messages to be encoded in protobuf format. * fpm/{fpm_pb.h,.gitignore,.Makefile.am} Add the fpm_pb library, which contains code for interfacing with the FPM using protobuf. * configure.ac Generate fpm/Makefile. * Makefile.am Add fpm subdirectory to build. * common.am Add flags to be used by clients of the fpm_pb library. Signed-off-by: Avneesh Sachdev <avneesh@sproute.com>
* zebra: Enable fpm module to connect to remote fpm serverUdaya Shankara KS2016-09-231-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | FPM aims to provide cross platform mechanism to support the scenario where the router has forwarding path distinct fromt the kernel.Commonly Hardware based fast path.Hence it is non-configurable paramter.This limits us to use funcationality to update FIB information to remote hosts, like SDN controller. This implementation provides the CLI to configure remote hosts and port information of remote fpm controller.Otherwise default fpm server will be localhost and default fpm port will be well know port 2620. * zebra_fpm.c: added fpm_server paramter to zfpm_global_t handler. Implemented CLI for configuring the fpm server and no fpm command to revert back to default configuration. * zserv.c: Install zebra node to write fpm configuration info on console/config file. Further documentation supplied: ------------------------------- ZEBRA : CLI CONFIGURATION FOR FPM MODULE ======================================================== 1. INTRODUCTION ================================ 1.1 scope This memo discusses the configuration option for zebra to update FIB information to local and remote modules. This will also helps to address the issue associated with CORD project. https://jira.onosproject.org/browse/CORD-411 2. REFERENCE ================================ Quagga version 99.24+ ( main branch committed on 29-sep-2015) 3. PROBLEM DESCRIPTION ================================ Once FPM is enabled, Quagga periodically tries to initiate fpm connection to localhost:2620. These values are non configurable in existing implementation. There is no CLI available to configure "host:port". hence limits us to use it for hardware based fast path modules only. 4. PROPOSED CHANGES ================================ Following changes are done to the quagga code a) Added new CLI to configure "host address : port". The CLI format <conf t> $ fpm connection ip <ipv4 address> port <tcp port num> and no fpm command to revert back to default <conf t> $ no fpm connection ip <ipv4 address> port <tcp port num> b) Allowed values are ipv4 address and tcp port range <1-65535> c) FPM initialization code has been enhanced to pick the "host address : port" values from zebra.conf. if not found then default values as localhost:2620 will be used. and updated the information on to config file on write config command 5. FILES MODIFIED ================================ 1) fpm/fpm.h : a) Added MACRO to represent network order loopback ip 2) zebra/zebra_fpm.h : a) introduced fpm_server variable in zfpm_glob_t handler to hold the remote fpm server address b) Hooked 'fpm_remote_ip_cmd' and 'no_fpm_remote_ip_cmd' at CONFIG node to configure remote fpm detail and to revert back to default respectively 3) zebra/zserv.c : a) Hooked 'config_write_fpm' callback function, at ZEBRA_NODE to display the fpm connection details on console on entering command $ show running_config and to write to configuration file on entering command $ write config 6. TESTING DETAILS ================================ 6.1. default behavior In default configuration FPM will attempt to connect to localhost:2620 6.2. update fpm info a) Using CLI command user can configure fpm host:port details and can be able to write to config file(zebra.conf) using write config command. this parameters has no dependency/impact on other parameters of config file b) show running-config/write config will display the fpm information if configured. and will not display any information related to fpm for default configuration c) these configured information will be stored to config file. only on write config command. 6.3 loading from config file a) zebra attempts to connect to fpm server if fpm parameter found in config file.else connects to default parameters. b) if fpm connection drops, fpm will periodically attempts to connect to remote server. c) if fpm connections already established. then newly configured fpm parameters will not disconnect the existing connection. new connection to the different fpm server will happen only after existing connection closes by either of the end. fix fpm prototype
* fpm: Add public header for Forwarding Plane ManagerAvneesh Sachdev2012-11-301-0/+273
The Forwarding Plane Manager (FPM) is an optional component that may be used in scenarios where the router has a forwarding path that is distinct from the kernel, commonly a hardware-based fast path. It is responsible for programming forwarding information (such as routes and nexthops) in the fast path. In Quagga, the Routing Information Base is maintained in the 'zebra' infrastructure daemon. Routing protocols communicate their best routes to zebra, and zebra computes the best route across protocols for each prefix. This latter information comprises the bulk of the Forwarding Information Base. The new header file added by this patch, 'fpm/fpm.h', defines a point-to-point interface using which zebra can update the FPM about changes in routes. The communication takes place over a stream socket. The FPM listens on a well-known TCP port, and zebra initiates the connection. All messages sent over the connection start with a short 'FPM header'. In the case of route add/delete messages, the header is followed by a netlink message. Zebra should send a complete copy of the forwarding table(s) to the FPM, including routes that it may have picked up from the kernel. The FPM interface uses replace semantics. That is, if a 'route add' message for a prefix is followed by another 'route add' message, the information in the second message is complete by itself, and replaces the information sent in the first message. If the connection to the FPM goes down for some reason, the client (zebra) should send the FPM a complete copy of the forwarding table(s) when it reconnects. Signed-off-by: Avneesh Sachdev <avneesh@opensourcerouting.org> Signed-off-by: David Lamparter <equinox@opensourcerouting.org>