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>
Add a hash_clean_and_free() function as well as convert
the code to use it. This function also takes a double
pointer to the hash to set it NULL. Also it cleanly
does nothing if the pointer is NULL( as a bunch of
code tested for ).
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
The "show zebra mpls .. json" vty command may return empty information
in case the MPLS database is empty or a given label entry is not
available. When those errors occur, add the braces to return a
valid json format.
Signed-off-by: Philippe Guibert <philippe.guibert@6wind.com>
Use the already existing mpls label code to store VNI
info for vxlan. VNI's are defined as labels just like mpls,
we should be using the same code for both.
This patch is the first part of that. Next we will need to
abstract the label code to not be so mpls specific. Currently
in this, we are just treating VXLAN as a label type and storing
it that way.
Signed-off-by: Stephen Worley <sworley@nvidia.com>
The wq->spec.errorfunc is never used in the code.
It's been in the code base since 2005 and I also
do not remember ever seeing it being called. No
workqueue process function ever returns error.
Since it's not used let's just remove it from the
code base.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Convert label processing that comes from zapi messages
into being handled by the meta-Q. This is because early
route processing is going to be moved to the meta-Q as
well and we will have a chicken and egg problem without
moving this code to be processed by the meta-Q.
Ordering of messages from ospf as an example:
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:48] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:62] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:43] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:61] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_ROUTE_ADD:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:66] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
2022/08/09 08:55:52.740 ZEBRA: [YXG8K-BCYMV] zebra message[ZEBRA_MPLS_LABELS_REPLACE:0:47] comes from socket [36]
The ZEBRA_MPLS_LABELS_REPLACE immediately turn around and attempt to replace nexthop labels on routes that
were added. If the route add is placed on the metaQ, it will not exist yet and as such the label replace
will fail.
Modify the zebra code to take the label operations and place them on the metaQ as well.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Currently when FRR starts up it queries the kernel to see if mpls is turned on.
If not FRR does not enable zebra's mpls subsection. If at a later time mpls
is turned on, let's notice that an interface now is enabled for mpls( thus
implying that all the bits and bobs in the kernel are now setup properly ).
a) convert mpls_enabled to a bool
b) abstract a new function zebra_mpls_turned_on and call it
when FRR notices that an interface now has mpls enabled.
c) mpls_processq_init cannot fail, so actually notice that
and don't have special code to detect a failure.
New results:
sharpd@eva ~> vtysh -c "show zebra"
OS Linux(5.10.0-12-amd64)
ECMP Maximum 128
v4 Forwarding On
v6 Forwarding On
MPLS Off
EVPN Off
Kernel socket buffer size 90000000
VRF l3mdev Available
ASIC offload Unavailable
RA Compiled in
RFC 5549 BGP is not using
Kernel NHG Available
v4 All LinkDown Routes Off
v4 Default LinkDown Routes Off
v6 All LinkDown Routes Off
v6 Default LinkDown Routes Off
v4 All MC Forwarding On
v4 Default MC Forwarding Off
v6 All MC Forwarding On
v6 Default MC Forwarding Off
Route Route Neighbor LSP LSP
VRF Installs Removals Updates Installs Removals
default 26 7 0 0 0
<turn on mpls_iptunnel and mpls_router modules in the kernel and then do this>:
sharpd@eva ~> sudo sysctl -w net.mpls.conf.enp39s0.input=1
[sudo] password for sharpd:
net.mpls.conf.enp39s0.input = 1
sharpd@eva ~> vtysh -c "show zebra"
OS Linux(5.10.0-12-amd64)
ECMP Maximum 128
v4 Forwarding On
v6 Forwarding On
MPLS On
EVPN Off
Kernel socket buffer size 90000000
VRF l3mdev Available
ASIC offload Unavailable
RA Compiled in
RFC 5549 BGP is not using
Kernel NHG Available
v4 All LinkDown Routes Off
v4 Default LinkDown Routes Off
v6 All LinkDown Routes Off
v6 Default LinkDown Routes Off
v4 All MC Forwarding On
v4 Default MC Forwarding Off
v6 All MC Forwarding On
v6 Default MC Forwarding Off
Route Route Neighbor LSP LSP
VRF Installs Removals Updates Installs Removals
default 26 7 0 0 0
sharpd@eva ~>
I am doing this work because FRR keeps having operators not know about how
to properly use mpls. Let's make FRR behave a bit better in this weird edge
case.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
==1595641== 280 (80 direct, 200 indirect) bytes in 1 blocks are definitely lost in loss record 30 of 38
==1595641== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1595641== by 0x493C89C: qcalloc (memory.c:116)
==1595641== by 0x1E8426: lsp_alloc (zebra_mpls.c:1116)
==1595641== by 0x49147F1: hash_get (hash.c:162)
==1595641== by 0x1EC880: mpls_lsp_install (zebra_mpls.c:3192)
==1595641== by 0x1C51BB: zread_vrf_label (zapi_msg.c:3197)
==1595641== by 0x1C6F11: zserv_handle_commands (zapi_msg.c:3863)
==1595641== by 0x24D0F4: zserv_process_messages (zserv.c:523)
==1595641== by 0x498F4CC: thread_call (thread.c:2002)
==1595641== by 0x49253A2: frr_run (libfrr.c:1198)
==1595641== by 0x1A28BA: main (main.c:475)
==1595641==
==1595641== 1,400 (400 direct, 1,000 indirect) bytes in 5 blocks are definitely lost in loss record 35 of 38
==1595641== at 0x483AB65: calloc (vg_replace_malloc.c:760)
==1595641== by 0x493C89C: qcalloc (memory.c:116)
==1595641== by 0x1E8426: lsp_alloc (zebra_mpls.c:1116)
==1595641== by 0x49147F1: hash_get (hash.c:162)
==1595641== by 0x1EBD7C: mpls_zapi_labels_process (zebra_mpls.c:2915)
==1595641== by 0x1C35D9: zread_mpls_labels_add (zapi_msg.c:2513)
==1595641== by 0x1C6F11: zserv_handle_commands (zapi_msg.c:3863)
==1595641== by 0x24D0F4: zserv_process_messages (zserv.c:523)
==1595641== by 0x498F4CC: thread_call (thread.c:2002)
==1595641== by 0x49253A2: frr_run (libfrr.c:1198)
==1595641== by 0x1A28BA: main (main.c:475)
Signed-off-by: Donatas Abraitis <donatas@opensourcerouting.org>
The rib_process_dplane_results function was having each
sub function handler process the results and then
free the ctx. Lot's of functionality that needs to remember
to free the context. Let's just free it in the main loop.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Firstly, *keep no change* for `hash_get()` with NULL
`alloc_func`.
Only focus on cases with non-NULL `alloc_func` of
`hash_get()`.
Since `hash_get()` with non-NULL `alloc_func` parameter
shall not fail, just ignore the returned value of it.
The returned value must not be NULL.
So in this case, remove the unnecessary checking NULL
or not for the returned value and add `void` in front
of it.
Importantly, also *keep no change* for the two cases with
non-NULL `alloc_func` -
1) Use `assert(<returned_data> == <searching_data>)` to
ensure it is a created node, not a found node.
Refer to `isis_vertex_queue_insert()` of isisd, there
are many examples of this case in isid.
2) Use `<returned_data> != <searching_data>` to judge it
is a found node, then free <searching_data>.
Refer to `aspath_intern()` of bgpd, there are many
examples of this case in bgpd.
Here, <returned_data> is the returned value from `hash_get()`,
and <searching_data> is the data, which is to be put into
hash table.
Signed-off-by: anlan_cs <vic.lan@pica8.com>
During zebra shutdown, we clear out the LSP workqueue. The LSPs
will be uninstalled and freed during the shutdown process, so
just ignore any LSPs that happen to be on the workqueue.
Signed-off-by: Mark Stapp <mstapp@nvidia.com>
Handle TYPE_IFINDEX nexthops more consistently in a few places;
be more specific about a few integer return values that were
being treated as booleans.
Signed-off-by: Mark Stapp <mjs.ietf@gmail.com>
There exists a call path where the nhlfe_alloc can return NULL
for blackhole nexthops. In this case we were still trying
to save the nhlfe pointer causing a crash when we attempted
to add it to a self-contained list.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Do not use the `default` case when switching over an enumerated
type. This allows the code to fail to compile when we add a
new enumeration. Thus allowing us developers to know all
the places in the code we'll need to touch.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
When creating a large number of vrf's we are creating a fairly
large number of hash tables per vrf. Reduce memory usage on
startup as well as let us identify the table these things come
from.
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Handle SR-TE policy changes in the LSP async notification
handler, as we do in the normal LSP dplane results handler.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
When certain events occur (connected route changes e.g.)
zebra examines LSPs to see if they might have been affected. For
LSPs with backup nhlfes, skip this immediate processing and
wait for the owning protocol daemon to react.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
This one also needed a bit of shuffling around, but MTYPE_RE is the only
one left used across file boundaries now.
Signed-off-by: David Lamparter <equinox@diac24.net>
Back when I put this together in 2015, ISO C11 was still reasonably new
and we couldn't require it just yet. Without ISO C11, there is no
"good" way (only bad hacks) to require a semicolon after a macro that
ends with a function definition. And if you added one anyway, you'd get
"spurious semicolon" warnings on some compilers...
With C11, `_Static_assert()` at the end of a macro will make it so that
the semicolon is properly required, consumed, and not warned about.
Consistently requiring semicolons after "file-level" macros matches
Linux kernel coding style and helps some editors against mis-syntax'ing
these macros.
Signed-off-by: David Lamparter <equinox@diac24.net>
There are several places where prefix2str was used to convert
a prefix but they were debug guarded and the buffer was
used for flog_err/warn. This would lead to corrupt data
being output in the failure cases if debugs were not turned
on.
Modify the code in zebra_mpls.c to not use prefix2str
Signed-off-by: Donald Sharp <sharpd@nvidia.com>
Use the same lsp and nexthop/nhlfe objects for 'static' and
dynamic LSPs; remove the 'static' objects and their supporting
code.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
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>
Improve vty output for routes and lsps with backups, including
json. Simplify or correct some code that uses both primary and
backup nexthops in dplane, nht.
Signed-off-by: Mark Stapp <mjs@voltanet.io>
