summaryrefslogtreecommitdiffstats
path: root/bgpd/bgp_labelpool.h (follow)
Commit message (Collapse)AuthorAgeFilesLines
* bgpd: Use synchronous way to get labels from ZebraDonatas Abraitis2023-06-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both the label manager and table manager zapi code send data requests via zapi to zebra and then immediately listen for a response from zebra. The problem here is of course that the listen part is throwing away any zapi command that is not the one it is looking for. ISIS/OSPF and PIM all have synchronous abilities via zapi, which they all do through a special zapi connection to zebra. BGP needs to follow this model as well. Additionally the new zclient_sync connection that should be created, a once a second timer should wake up and read any data on the socket to prevent problems too much data accumulating in the socket. ``` r3# sh bgp labelpool summary Labelpool Summary ----------------- Ledger: 3 InUse: 3 Requests: 0 LabelChunks: 1 Pending: 128 Reconnects: 1 r3# sh bgp labelpool inuse Prefix Label --------------------------- 10.0.0.1/32 16 192.168.31.0/24 17 192.168.32.0/24 18 r3# ``` Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* bgpd: add LP_TYPE_BGP_L3VPN_BIND label typeLouis Scalbert2023-06-161-0/+1
| | | | | | | | | | | | | | | | | | | Redistributing mpls vpn prefixes with a new label requires picking up unused MPLS local labels. Today, there is an MPLS label pool which is owned by the zebra daemon. BGP gets a chunk of labels that are shared with the multiple usage of the BGP daemon. A label type attribute is used whenever BGP needs a new label value. The 'LP_TYPE_BGP_L3VPN_BIND' label type will be used to allocate the MPLS labels that will be bound to the original next-hop, and label value of an L3VPN update. Signed-off-by: Louis Scalbert <louis.scalbert@6wind.com> Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: add 'show bgp label-nexthop [detail]' commandPhilippe Guibert2023-05-091-0/+1
| | | | | | | | | | | | | | | | | | | | | | The following command is made available to list the labels allocated per-nexthop, along with the paths registered to it. > # show bgp vrf vrf1 label-nexthop > Current BGP label nexthop cache for IP, VRF vrf1 > 192.0.2.11, label 20 #paths 3 > if r1-eth1 > Last update: Mon Jan 16 18:52:11 2023 > 192.0.2.12, label 17 #paths 2 > if r1-eth1 > Last update: Mon Jan 16 18:52:08 2023 > 192.0.2.14, label 18 #paths 1 > if r1-eth1 > Last update: Mon Jan 16 18:52:07 2023 > 192.168.255.13, label 19 #paths 1 > if r1-eth2 > Last update: Mon Jan 16 18:52:10 2023 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: update time of last change when label nexthop entry changedPhilippe Guibert2023-05-091-0/+2
| | | | | | | | | A timer attribute is added for each label nexthop entry, in order to know when the last change occured. The timer value will be used for troubleshooting by a show command in the next commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: use nexthop interface when adding LSP in BGP MPLSVPNPhilippe Guibert2023-05-091-0/+5
| | | | | | | | | | | | | BGP MPLSVPN next hop label allocation was using only the next-hop IP address. As MPLSVPN contexts rely on bnc contexts, the real nexthop interface is known, and the LSP entry to enter can apply to the specific interface. To illustrate, the BGP service is able to handle the following two iproute2 commands: > ip -f mpls route add 105 via inet 192.0.2.45 dev r1-eth1 > ip -f mpls route add 105 via inet 192.0.2.46 dev r1-eth2 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: add the bgp_label_per_nexthop_cache struct and apisPhilippe Guibert2023-05-091-0/+43
| | | | | | | | | | | | | This commit introduces the necessary structs and apis to create the cache entries that store the label information associated to a given nexthop. A hash table is created in each BGP instance for all the AFIs: IPv4 and IPv6. That hash table is initialised. An API to look and/or create an entry based on a given nexthop. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* bgpd: introduce LP_TYPE_NEXTHOP label typePhilippe Guibert2023-05-091-0/+1
| | | | | | | | | | A new label type is introduced: LP_TYPE_NEXTHOP. This new label type will be used in next commits to allocate labels for a specific nexthop IP address. The commit changes add vty and json outputs to display the new label type and the label values associated. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* Revert "MPLS allocation mode per next hop"Donatas Abraitis2023-05-031-52/+0
| | | | | | Broken tests, let's revert now. Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
* Merge pull request #12646 from pguibert6WIND/mpls_alloc_per_nhDonatas Abraitis2023-05-021-0/+52
|\ | | | | MPLS allocation mode per next hop
| * bgpd: add 'show bgp label-nexthop [detail]' commandPhilippe Guibert2023-03-221-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following command is made available to list the labels allocated per-nexthop, along with the paths registered to it. > # show bgp vrf vrf1 label-nexthop > Current BGP label nexthop cache for IP, VRF vrf1 > 192.0.2.11, label 20 #paths 3 > if r1-eth1 > Last update: Mon Jan 16 18:52:11 2023 > 192.0.2.12, label 17 #paths 2 > if r1-eth1 > Last update: Mon Jan 16 18:52:08 2023 > 192.0.2.14, label 18 #paths 1 > if r1-eth1 > Last update: Mon Jan 16 18:52:07 2023 > 192.168.255.13, label 19 #paths 1 > if r1-eth2 > Last update: Mon Jan 16 18:52:10 2023 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * bgpd: update time of last change when label nexthop entry changedPhilippe Guibert2023-03-221-0/+2
| | | | | | | | | | | | | | | | | | A timer attribute is added for each label nexthop entry, in order to know when the last change occured. The timer value will be used for troubleshooting by a show command in the next commit. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * bgpd: use nexthop interface when adding LSP in BGP MPLSVPNPhilippe Guibert2023-03-221-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | BGP MPLSVPN next hop label allocation was using only the next-hop IP address. As MPLSVPN contexts rely on bnc contexts, the real nexthop interface is known, and the LSP entry to enter can apply to the specific interface. To illustrate, the BGP service is able to handle the following two iproute2 commands: > ip -f mpls route add 105 via inet 192.0.2.45 dev r1-eth1 > ip -f mpls route add 105 via inet 192.0.2.46 dev r1-eth2 Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * bgpd: add the bgp_label_per_nexthop_cache struct and apisPhilippe Guibert2023-03-221-0/+43
| | | | | | | | | | | | | | | | | | | | | | | | | | This commit introduces the necessary structs and apis to create the cache entries that store the label information associated to a given nexthop. A hash table is created in each BGP instance for all the AFIs: IPv4 and IPv6. That hash table is initialised. An API to look and/or create an entry based on a given nexthop. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
| * bgpd: introduce LP_TYPE_NEXTHOP label typePhilippe Guibert2023-03-221-0/+1
| | | | | | | | | | | | | | | | | | | | A new label type is introduced: LP_TYPE_NEXTHOP. This new label type will be used in next commits to allocate labels for a specific nexthop IP address. The commit changes add vty and json outputs to display the new label type and the label values associated. Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
* | *: Convert `struct event_master` to `struct event_loop`Donald Sharp2023-03-241-1/+1
| | | | | | | | | | | | Let's find a better name for it. Signed-off-by: Donald Sharp <sharpd@nvidia.com>
* | *: Convert struct thread_master to struct event_master and it's ilkDonald Sharp2023-03-241-1/+1
|/ | | | | | | Convert the `struct thread_master` to `struct event_master` across the code base. 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>
* bgpd: improve labelpool performance at scaleG. Paul Ziemba2022-08-311-0/+1
| | | | | | | | | | | | | | - double the size of each new chunk request from zebra - use bitfields to track label allocations in a chunk - When allocating: - skip chunks with no free labels - search biggest chunks first - start search in chunk where last search ended - Improve API documentation in comments (bgp_lp_get() and callback) - Tweak formatting of "show bgp labelpool chunks" - Add test features (compiled conditionally on BGP_LABELPOOL_ENABLE_TESTS) Signed-off-by: G. Paul Ziemba <paulz@labn.net>
* *: require semicolon after DEFINE_<typesafe...>David Lamparter2021-03-171-1/+1
| | | | | | Again, see previous commits. Signed-off-by: David Lamparter <equinox@diac24.net>
* bgpd: add show commands for bgp labelpoolPat Ruddy2021-01-041-0/+2
| | | | | | | These commands allow the bgp labelpool lists and counts to be viewed for debug purposes. Signed-off-by: Pat Ruddy <pat@voltanet.io>
* bgpd: replace label pool fifo with DECLARE_LISTDavid Lamparter2019-04-271-1/+3
| | | | | | | Again, the FIFO_* stuff in lib/fifo.h is no different from a simple unsorted list. Just use DECLARE_LIST here so we can get rid of FIFO_*. Signed-off-by: David Lamparter <equinox@opensourcerouting.org>
* bgpd, zebra: auto assign labels from label pool to regular prefixes in BGP ↵Anton Degtyarev2018-12-201-0/+1
| | | | | | | | | | | | labeled unicast This commit is the last missing piece to complete BGP LU support in bgpd. To this moment, bgpd (and zebra) supported auto label assignment only for prefixes leaked from VRFs to vpn and for MPLS SR prefixes. This adds auto label assignment to other routes types in bgpd. The following enhancements have been made: * bgp_route.c:bgp_process_main_one() now sets implicit-null local_label to all local, aggregate and redistributed routes. * bgp_route.c:bgp_process_main_one() now will request a label from the label pool for any prefix that loses the label for some reason (for example, when the static label assignment config is removed) * bgp_label.c:bgp_reg_dereg_for_label() now requests labels from label pool for routes which have no associated label index * zebra_mpls.c:zebra_mpls_fec_register() now expects both label and label_index from the calling function, one of which must be set to MPLS_INVALID_LABEL or MPLS_INVALID_LABEL_INDEX, based on this it will decide how to register the provided FEC. Signed-off-by: Anton Degtyarev <anton@cumulusnetworks.com>
* bgpd: dynamic mpls label poolG. Paul Ziemba2018-04-121-0/+51
MPLS label pool backed by allocations from the zebra label manager. A caller requests a label (e.g., in support of an "auto" label specification in the CLI) via lp_get(), supplying a unique ID and a callback function. The callback function is invoked at a later time with the unique ID and a label value to inform the requestor of the assigned label. Requestors may release their labels back to the pool via lp_release(). The label pool is stocked with labels allocated by the zebra label manager. The interaction with zebra is asynchronous so that bgpd is not blocked while awaiting a label allocation from zebra. The label pool implementation allows for bgpd operation before (or without) zebra, and gracefully handles loss and reconnection of zebra. Of course, before initial connection with zebra, no labels are assigned to requestors. If the zebra connection is lost and regained, callbacks to requestors will invalidate old assignments and then assign new labels. Signed-off-by: G. Paul Ziemba <paulz@labn.net>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-12 09:03:57 +0100